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PREFACE 


This  development  specification  covers  the  work  performed 
under  Air  Force  Contract  F33615-80-C-5155  (ICAM  Project  6201). 
This  contract  is  sponsored  by  the  Materials  Laboratory,  Air 
Force  Systems  Command,  Wright-Patterson  Air  Force  Base,  Ohio. 

It  was  administered  under  the  technical  direction  of  Mr.  Gerald 
C.  Shumaker,  ICAM  Program  Manager,  Manufacturing  Technology 
Division,  through  Project  Manager,  Mr.  David  Judson.  The  Prime 
Contractor  was  Production  Resources  Consulting  of  the  General 
Electric  Company,  Schenectady,  New  York,  under  the  direction  of 
Mr.  Alan  Rubenstein.  The  General  Electric  Project  Manager  was 
Mr.  Myron  Hurlbut  of  Industrial  Automation  Systems  Department. 
Albany,  New  York. 

Certain  work  aimed  at  improving  Test  Bed  Technology  has 
been  performed  by  other  contracts  with  Project  6201  performing 
integrating  functions.  This  work  consisted  of  enhancements  to 
Test  Bed  software  and  establishment  and  operation  of  Test  Bed 
hardware  and  communications  for  developers  and  other  users. 
Documentation  relating  to  the  Test  Bed  from  all  of  these 
contractors  and  projects  have  been  integrated  under  Project  6201 
for  publication  and  treatment  as  an  integrated  set  of  documents. 
The  particular  contributors  to  each  document  are  noted  on  the 
Report  Documentation  Page  (DD1473).  A  listing  and  description 
of  the  entire  project  documentation  system  and  how  they  are 
related  is  contained  in  document  FTR620100001 ,  Project  Overview. 

The  subcontractors  and  their  contributing  activities  were 
as  follows: 


TASK  4.2 

Subcontractors  Role 

Boeing  Military  Aircraft  Reviewer. 

Company  ( BMAC ) 

D.  Appleton  Company  Responsible  for  IDEF  support, 

(DAC0M)  state-of-the-art  literature 

search . 

General  Dynamics/  Responsible  for  factory  view 

Ft.  Worth  function  and  information 

models . 
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Subcontractors 


Role 


Illinois  Institute  of 
Technology 


North  American  Rockwell 
Northrop  Corporation 

Pritsker  and  Associates 
SofTech 


Responsible  for  factory  view 
function  research  (IITRI) 
said  information  models  of 
small  and  medium-size  business 

Reviewer . 

Responsible  for  factory  view 
function  and  information 
models . 

Responsible  for  IDEF2  support. 
Responsible  for  IDEFO  support. 


TASKS  4.3  -  4.9  (TEST  BED) 

Subcontractors 

Boeing  Military  Aircraft 
Company  ( BMAC ) 


Computer  Technology 
Associates  (CTA) 


Control  Data  Corporation 
( CDC ) 


D.  Appleton  Company 
(DACOM) 


Role 

Responsible  for  consultation  on 
applications  of  the  technology 
and  on  IBM  computer  technology. 

Assisted  in  the  areas  of 
communications  systems,  system 
design  and  integration 
methodology,  and  design  of  the 
Network  Transaction  Manager. 


Responsible 
Model  ( CDM ) 
part  of  the 
with  DACOM) 


for  the  Common  Data 
implementation  and 
CDM  design  (shared 


Responsible  for  the  overall  CDM 
Subsystem  design  integration 
and  test  plan,  as  well  as  part 
of  the  design  of  the  CDM 
(shared  with  CDC).  DACOM  also 
developed  the  Integration 
Methodology  and  did  the  schema 
mappings  for  the  Application 
Subsystems . 
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Subcontractors 


Role 


Digital  Equipment 
Corporation  (DEC) 


McDonne 1 1  Doug 1 as 
Automation  Company 
(McAuto) 


On-Line  Software 
International  (OSI) 


Consulting  and  support  of  the 
performance  testing  and  on  DEC 
software  and  computer  systems 
operation. 

Responsible  for  the  support  and 
enhancements  to  the  Network 
Transaction  Manager  Subsystem 
during  1984/1985  period. 

Responsible  for  programming  the 
Communications  Subsystem  on  the 
IBM  and  for  consulting  on  the 
IBM. 


Rath  and  Strong  Systems 
Products  (RSSP)  (In  1985 
became  McCormack  B  Dodge) 


SofTech,  Inc. 


Software  Performance 
Engineering  (SPE) 


Structural  Dynamics 
Research  Corporation 
( SDRC ) 


Responsible  for  assistance  in 
the  implementation  and  use  of 
the  MRP  II  package  (PIOS)  that 
they  supplied. 

Responsible  for  the  design  and 
Implementation  of  the  Network 
Transaction  Manager  (NTM)  in 
1981/1984  period. 

Responsible  for  directing  the 
work  on  performance  evaluation 
and  analysis. 

Responsible  for  the  User 
Interface  and  Virtual  Terminal 
Interface  Subsystems. 


Other  prime  contractors  under  other  projects  who  have 
contributed  to  Test  Bed  Technology,  their  contributing 
activities  and  responsible  projects  are  as  follows: 


Contractors 

ICAM  Project 

Contributing  Activities 

Boeing  Military 

1701,  2201, 

Enhancements  for  IBM 

Aircraft  Company 

2202 

node  use.  Technology 

( BMAC ) 

Transfer  to  Integrated 
Sheet  Metal  Center 

( I SMC) . 
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Contractors 

ICAM  Pro.ject 

Contributing  Activities 

Control  Data 
Corporation  (CDC) 

1502,  1701 

I1SS  enhancements  to 
Common  Data  Model 
Processor  (CDMP). 

D.  Appleton  Company 
(DACOM) 

1502 

IISS  enhancements  to 
Integration  Methodology 

General  Electric 

1502 

Operation  of  the  Test 
Bed  and  communications 
equipment . 

Hughes  Aircraft 

Company  ( HAC ) 

1701 

Test  Bed  enhancements. 

Structural  Dynamics 
Research  Corporation 
(SDRC) 

1502,  1701, 
1703 

IISS  enhancements  to 
User  Interface/Virtual 
Terminal  Interface 
(UI/VTI ) . 

Systran 

1502 

Test  Bed  enhancements . 
Operation  of  Test  Bed. 
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SECTION  1 
SCOPE 


1 . 1  Ident i f i cat i on 

>  This  specification  establishes  the  detailed  requirements 
for  performance,  design,  test,  and  qualification  of  a  computer 
program  identified  as  the  Forms  Definition  Language  Compiler, 
hereinafter  referred  to  as  FLAN.  FLAN  is  one  configuration 
item  of  the  Integrated  Information  Support  System  User  Interface 
C IISS  UI)  . 

1 .2  Functional  Summary 

FLAN  is  used  to  compile  Form  Definition  Language  source 
files  into  binary  Form  Definition  File  format.  Form  Definition 
files  are  used  as  input  to  the  Form  Processor  in  displaying  the 
forms.  REVFLAN  is  used  to  create  a  Form  Definition  Language 
source  file  from  one  or  more  version  1.0  Form  Definition  Files 
which  were  derived  from  the  DEC  FMS  utility  before  FLAN  was 
implemented  and  which  had  no  source  file.  MAKINC  creates 
program  variable  declarations  which  correspond  to  the  structure 
of  a  form  and  are  useful  to  application  programs  which  make  use 
of  Form  Processor  calls  to  PDATA  and  GDATA. 


The  parser  and  some  procedures  of  FLAN  are  used  by  the 
Forms  Driven  Forms  Editor  ( FDFE ) ,  the  Report  Writer  (RW),  and 
the  Rapid  Application  Generator  (RAP)  (all  three  of  which  are 
configuration  items).  This  ensures  that  the  language  which  is 
accepted  by  them  is  identical. 
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2 . 1  Reference  Documents 

[1]  I CAM  Documentation  Standards,  ICAM  Document  IDS 
150120000C ,  15  September  1983. 

[2]  IISS  Integration  Task  Force,  Final  Report ,  1984. 

[3]  A.  V.  Aho  and  J.  D.  Ullman,  Principles  of  Compi ler 
Design,  Addison-Wesley ,  1977. 

[4]  S.  C.  Johnson,  "YACC:  Yet  Another  Compiler-Compiler,” 
UNIX*  Programmer ' s  Manual,  Seventh  Edition,  Vol .  2, 
Bell  Laboratories,  1983. 

[5]  General  Electric  Co.,  System  Design  Specification ,  7 
February  1983. 

[6]  Structural  Dynamics  Research  Corporation,  Report 
Writer  Development  Specification,  DS  620144501, 

1  November  1985 . 

[7]  Structural  Dynamics  Research  Corporation,  Rapid 
Appl i cat ion  Generator  Development  Specification, 

DS  620144502  ,  1  November  1985. 

[8]  Structural  Dynamics  Research  Corporation,  Text 
Editor  Development  Specification,  DS  620144600B, 

1  November  1985. 

[9]  Structural  Dynamics  Research  Corporation,  Form 
Processor  Development  Specification,  DS  620144200B, 

1  November  1985. 

[10]  Structural  Dynamics  Research  Corporation,  Appl i cat ion 
Interface  Development  Specification,  DS  620144700  , 

1  November  1985. 

[11]  Structural  Dynamics  Research  Corporation,  Forms 
Language  Compi ler  Development  Specification, 

DS  620144401B,  1  November  1985. 

*  UNIX  is  a  trademark  of  ATSfT  Bell  Laboratories. 
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[12]  Structural  Dynamics  Research  Corporation,  Forms 
Driven  Form  Edi tor  Development  Specification , 

DS  620144402B ,  1  November  1985. 

[13]  Structural  Dynamics  Research  Corporation,  User 
Interface  Services  Development  Specification , 

DS  620144100B,  1  November  1985. 

[14]  Structural  Dynamics  Research  Corporation,  Virtual 
Terminal  Development  Specification,  DS  620144300B, 

1  November  1985. 

2 . 2  Terms  and  Abbreviations 

Appl i cat  ion  Definition  Language :  an  extension  of  the  Forms 
Definition  Language  that  includes  retrieval  of  database 
information  and  conditional  actions.  It  is  used  to  define 
interactive  application  programs. 

Attribute :  field  characteristic  such  as  blinking, 
highlighted,  black,  etc.  and  various  other  combinations. 
Background  attributes  are  defined  for  forms  or  windows  only. 
Foreground  attributes  are  defined  for  items.  Attributes  may  be 
permanent,  i.e.,  they  remain  the  same  unless  changed  by  the 
application  program,  or  they  may  be  temporary,  i.e.,  they  remain 
in  effect  until  the  window  is  redisplayed. 

Common  Data  Model :  (CDM) ,  IISS  subsystem  that  describes 
common  data  application  process  formats,  form  definitions,  etc. 
of  the  IISS  and  includes  conceptual  schema,  external  schemas, 
internal  schemas,  and  schema  transformation  operators. 

Pi  splay  List:  is  similar  to  the  open  list,  except  that  it 
contains  only  those  forms  that  have  been  added  to  the  screen  and 
are  currently  displayed  on  the  screen. 

Field :  two-dimensional  space  on  a  terminal  screen. 

Form:  structured  view  which  may  be  imposed  on  windows  or 
other  forms.  A  form  is  composed  of  fields.  These  fields  may  be 
defined  as  forms,  items,  and  windows. 

Form  Definition:  (FD),  forms  definition  language  after 
compilation.  It  is  read  at  runtime  by  the  Form  Processor. 
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Forms  Definition  Language :  (FDL),  the  language  in  which 
electronic  forms  are  defined. 

Form  Editor :  (FE),  subset  of  the  IISS  User  Interface  that 
is  used  to  create  definitions  of  forms.  The  FE  consists  of  the 
Forms  Driven  Form  Editor  and  the  Forms  Language  Compiler. 

Form  Hierarchy :  a  graphic  representation  of  the  way  in 
which  forms,  items  and  windows  are  related  to  their  parent  form. 

Forms  Language  Compiler :  (FLAN),  subset  of  the  FE  that 
consists  of  a  batch  process  that  accepts  a  series  of  forms 
definition  language  statements  and  produces  form  definition 
files  as  output. 

Form  Processor :  (FP),  subset  of  the  IISS  User  Interface 
that  consists  of  a  set  of  callable  execution  time  routines 
available  to  an  application  program  for  form  processing. 

Integrated  Information  Support  System:  (IISS),  a  test 
computing  environment  used  to  investigate,  demonstrate  and  test 
the  concepts  of  information  management  and  information 
integration  in  the  context  of  Aerospace  Manufacturing.  The  IISS 
addresses  the  problems  of  integration  of  data  resident  on 
heterogeneous  data  bases  supported  by  heterogeneous  computers 
interconnected  via  a  Local  Area  Network. 

Item:  non-decomposable  area  of  a  form  in  which  hard-coded 
descriptive  text  may  be  placed  and  the  only  defined  areas  where 
user  data  may  be  input/output. 

Message :  descriptive  text  which  may  be  returned  in  the 
standard  message  line  on  the  terminal  screen.  They  are  used  to 
warn  of  errors  or  provide  other  user  information. 


K  i 


Operating  System:  (OS),  software  supplied  with  a  computer 
which  allows  it  to  supervise  its  own  operations  and  manage 
access  to  hardware  facilities  such  as  memory  and  peripherals. 


Page :  instance  of  forms  in  windows  that  are  created 
whenever  a  form  is  added  to  a  window. 


Pag i ng  and  Scrol 1 ing :  a  method  which  allows  a  form  to 
contain  more  data  than  can  be  displayed  with  provisions  for 
viewing  any  portion  of  the  data  buffer. 
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Qual if ied  Name :  the  name  of  a  form,  item  or  window  preceded 
by  the  hierarchy  path  so  that  it  is  uniquely  identified. 

Subform :  a  form  that  is  used  within  another  form. 

User  Interface:  (UI),  IISS  subsystem  that  controls  the 
user's  terminal  and  interfaces  with  the  rest  of  the  system.  The 
UI  consists  of  two  major  subsystems:  the  User  Interface 
Development  System  (UIDS)  and  the  User  Interface  Management 
System  (UIMS). 

User  Interface  Development  System :  (UIDS),  collection  of 
IISS  User  Interface  subsystems  that  are  used  by  applications 
programmers  as  they  develop  IISS  applications.  The  UIDS 
includes  the  Form  Editor  and  the  Application  Generator. 

Window :  dynamic  area  of  a  terminal  screen  on  which 
predefined  forms  may  be  placed  at  run  time. 
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SECTION  3 
REQUIREMENTS 


3 . 1  Computer  Program  Definition 

FLAN  is  a  compiler  which  translates  Form  Definition 
Language  source  files  into  binary  Form  Definition  File  format. 
The  binary  Form  Definition  Files  are  then  used  as  input  by  the 
Form  Processor  (another  configuration  item  of  the  IISS  UI)  for 
display  and  entry  of  data  under  the  control  of  other  application 
programs . 

While  FLAN  is  normally  invoked  from  the  IISS  function 
screen,  another  version  is  available  which  can  be  invoked  from 
the  host  system.  This  second  version  is  required  so 
configuration  management  software  can  be  used  in  managing  Forms 
Definition  Language  files  in  a  manner  similar  to  other  source 
files. 

In  order  to  ease  the  conversion  of  forms  which  were  not 
created  using  the  Forms  Definition  Language.  REVFLAN  is  used. 
REVFLAN  is  a  program  used  to  create  a  Forms  Defintion  Language 
source  file  from  one  or  more  version  1.0  binary  Form  Definition 
files  which  were  created  using  the  DEC  FMS .  The  resulting  Form 
Definition  Language  file  may  then  be  FLANed  to  produce  version 
2.0  binary  Form  Definition  files.  REVFLAN  is  invoked  from  the 
host  system. 

MAKINC  is  a  program  that  creates  program  variable 
declarations  which  correspond  to  the  structure  of  a  form  and  may 
be  used  in  application  programs  which  make  use  of  the  Form 
Processor  calls  PDATA  and  GDATA.  The  following  programming 
languages  are  supported:  PL'I.  COBOL,  and  C.  MAKINC  is  invoked 
from  the  host  system. 

3.1.1  System  Capacities 

FLAN  is  written  in  the  C  programming  language  and  runs  on  a 
DEC  VAX  minicomputer  under  the  VMS  operating  system. 
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3.1.2  Interface  Requirements 

FLAN  may  be  invoked  from  the  IISS  function  screen  or  from 
the  host  system.  In  either  case  the  user  specifies  a  Forms 
Definition  Language  (FDL)  source  file  to  be  compiled  and  FLAN 
will  then  output  binary  Form  Definition  (FD)  files.  Error 
messages  are  directed  to  the  user's  terminal. 

The  format  of  the  binary  Form  Definition  Files  produced  by 
FLAN  is  constrained  to  agree  with  the  format  expected  by  the 
Form  Processor  configuration  item. 

The  syntax  of  the  Form  Definition  Language  accepted  as 
input  is  based  on  the  preliminary  syntax  developed  by  the  IISS 
Integration  Task  Force  and  reported  in  their  Final  Report.  FLAN 
also  accepts  statements  of  the  Report  Writer  language  and  the 
Application  Generator  language  but  performs  no  semantic 
processing  on  those  statements. 

REVFLAN  is  invoked  from  the  host  system.  The  user  is 
prompted  for  the  name  of  the  Forms  Definition  Language  file  that 
REVFLAN  will  create  and  for  the  name  of  each  binary  Form 
Definition  file  that  is  to  be  reverse  compiled. 

MAKINC  is  invoked  from  the  host  system.  The  user  is 
prompted  for  the  computer  programming  language,  the  name  of  the 
output  file  and  for  each  form  for  which  program  variable 
declarations  are  desired. 

3. 1.2.1  Interface  Block  Diagram 

The  interface  block  diagram  for  FLAN  is  shown  in  Figure 
3-1  The  top  box  represents  the  file  MYFORMS.FDL  which  is  input 
to  the  FLAN  compiler  (second  box).  FLAN  produces  a  FD  file  for 
each  CREATE  FORM  statement  in  the  source  file.  Each  FD  file  is 
input  for  the  Form  Processor  which  is  part  of  the  User  Interface 
system  Binary  Form  Definitions  are  also  input  to  REVFLAN  which 
produces  a  FDL  file  and  MAKINC  which  produces  a  file  with 
program  variable  declarations. 
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MYFORMS . FDL 

+ - + 

I  l 

I  CREATE  FORM  FI  I 

I  Background  Black  i 

I  Prompt  t 
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t  "Form  FI"  i 

l  Item  A  i 


CREATE  FORM  F2 


CREATE  FORM  F3 
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i  data  i 
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FLAN 
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+ - + - + 

I  t  I 
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+  - 

variable  i 

declarations  i 

Figure  3-1  FLAN  Interfaces 


DS  620 14440 IB 
1  November  1985 


3. 1.2. 2  Detailed  Interface  Definition 

3. 1.2. 2.1  Form  Language  Compiler  Interfaces 

3. 1.2. 2. 1.1  Form  Definition  Language 

The  syntax  of  the  Form  Definition  Language  accepted  as 
input  by  FLAN  is  documented  in  Appendix  A.  This  language  is 
intended  to  provide  access  to  all  Form  Processor  functionality. 
It  is  also  intended  to  be  a  LALR(l)  Grammar  for  ease  of  parsing. 
A  number  of  automatic  parser  generators  are  available  for 
LALR( 1 )  grammars,  most  notably  the  UNIX*  utility  YACC. 

3. 1.2. 2. 1.2  Binary  Form  File  Format 

The  formats  of  the  records  in  the  binary  Form  Definition 
Files  produced  as  output  by  FLAN  are  documented  in  the  include 
file  FFFV2.H,  contained  in  Appendix  B.  The  sequence  of  records 
in  the  file  is: 

1)  The  version  record  which  identifies  the  file  format. 

2)  The  form  record  for  the  form. 

3)  A  text  record  for  each  prompt  (both  form  prompts  and 
field  prompts). 

4)  A  field  record  for  each  field. 

5)  The  text  of  all  of  the  prompts  divided  into  80  character 
records . 

6)  The  default  values  of  all  of  the  fields  divided  into  80 
character  records . 

3. 1.2. 2. 1.3  User  Input  to  FLAN 

The  following  is  the  IISS  form  FLAN  uses  to  prompt  the  user 
for  an  input  file. 

•UNIX  is  a  trademark  of  AT&T  Bell  Laboratories 
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IISS  Forms  Definition  Language  Compiler  Release  2.0 


Forms  Definition  Language  File  Name: 


Msg:  0 


applcation 


Figure  3-2  FLAN  screen 

The  host  system  invocation  of  FLAN  is  system  dependent. 

The  user  specifies  a  Forms  Definition  Language  (FDL)  source  file 
to  be  compiled  and  FLAN  will  then  output  binary  Form  Definition 
(FD)  files  Error  messages  are  directed  to  the  user's 
terminal . 

3. 1.2. 2. 1.4  FLAN  Error  Messages 


FLAN  error  messages  are  of  the  format: 

line  number:  type  -  message  text 

Where  line  number  is  the  number  of  the  line  on  which  the  error 
occurred  Type  is  either  WARNING.  ERROR,  or  FATAL  WARNING 
messages  do  not  prevent  FD  file  generation  but  indicate 
potential  runtime  problems  ERROR  messages  are  sufficiently 
serious  to  prevent  FD  file  generation  but  error  checking 
continues  for  the  rest  of  the  file  FATAL  messages  prevent  all 
further  compilation 
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3. 1.2. 2. 2  REVFLAN  Interfaces 

The  invocation  of  REVFLAN  is  system  dependent.  The  user  is 
prompted  for  the  name  of  the  Forms  Definition  Language  file  that 
REVFLAN  will  create  and  for  the  name  of  each  binary  Form 
Definition  file  that  is  to  be  reverse  compiled. 

3. 1.2. 2. 3  MAKINC  Interfaces 

The  invocation  of  MAKINC  is  system  dependent.  The  user  is 
prompted  for  the  computer  programming  language,  the  name  of  the 
output  file  and  for  each  form  for  which  program  variable 
declarations  are  desired. 


Detailed  Functional  Requirements 


3.2.1  FLAN  Functional 


ruirements 


FLAN  allows  one  to  specify  the  following  items  required  by 
the  Form  Processor  and  which  are  discussed  in  detail  in  the  Form 
Processor  s  Developement  Specification: 

1)  Array. 

2)  Attribute. 

3)  Field. 

4)  Form. 

5)  Help  form. 

6)  Item. 

7)  Prompt. 

8)  Subform. 

9 )  W i ndow . 

FLAN  is  strictly  a  transformational  process  --  its  sole 
function  is  to  translate  data  from  one  format  to  another,  both 
of  which  are  well  defined  To  accomplish  this  transformation  in 
the  most  useful  manner  (where  useful  is  defined  as  providing 
functions  which  will  be  of  use  to  other  CIs  which  are  currently 
planned),  the  following  internal  data  structures  are  used. 
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FIELD  attmap 

- +  + - +  + - 

opnlst  i - >i  nxtfld  I  i  name 

- +  + - +  + - 
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+ - +  i  + - 
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+  i  v 

i  + - +  field 
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i  + - +  text 
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ENODE 


+ - + 
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Figure  3-3  Major  Internal  Data  Structures 


As  statements  are  read  in  and  recognized,  an  internal  data 
structure  is  created  and  filled  in.  This  data  structure  is 
identical  to  the  one  used  by  the  Form  Processor.  Figure  3-2 
illustrates  this  data  structure.  Note  that  pointers  in  the 
figure  which  are  not  shown  pointing  to  anything  represent  linked 
lists  of  items  of  the  type  containing  the  pointer.  All  of  these 
lists  contain  zero  or  more  entries  depending  on  the  input  data. 
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After  all  of  the  input  statements  have  been  read  in  and 
processed  and  the  internal  data  structure  created  and  filled  in 
without  error,  the  contents  of  the  internal  data  structure  are 
recorded  in  binary  form  files. 

When  a  processing  error  does  occur,  an  error  message  is 
issued  to  the  terminal  specifying  as  much  information  as 
possible  about  the  nature  of  the  error  and  the  location  of  the 
input  statement  causing  it.  When  possible,  processing  continues 
after  an  error  is  recognized  so  that  additional  errors  may  also 
be  detected. 

3.2  2  REVFLAN  Functional  Requirements 

REVFLAN  is  strictly  a  transformational  process  --  its  sole 
function  is  to  translate  data  from  one  format  to  another,  both 
of  which  are  well  defined.  The  input  to  REVFLAN  is  constrained 
to  agree  with  the  version  1  binary  Form  Definition  files 
accepted  by  the  Form  Processor.  Its  output  is  Form  Definition 
Language  source  which  is  syntacticly  and  semanticly  acceptable 
input  to  FLAN.  When  input  to  FLAN  the  output  will  be  quivalent 
version  2  FD  files. 


3.2.3  MAKINC  Functional  Requirements 


name 


These 


MAKINC  is  strictly  a  transformational  process  --  its  sole 
function  is  to  translate  data  from  one  format  to  another,  both 
of  which  are  well  defined.  The  input  to  MAKINC  is  constrained 
to  agree  with  version  2  binary  Form  Definition  files  accepted  b^ 
the  Form  Processor.  The  output  is  a  set  of  program  variable 
declarations  which  are  syntacticly  and  semanticly  correct  for 
the  language  of  choice  and  which  correspond  (in  structure,  name 
and  size)  to  the  forms  and  fields  in  the  FD  file.  These 
programming  languages  include: 

1  )  C  . 

2)  COBOL. 

3)  PL/ I. 

3 . 3  Performance  Requirements 
3.3.1  Programming  Methods 


A  parser  generator,  YACC,  is  used  to  create  the  parser  and 
existing  Form  Processor  routines  are  used  as  appropriate  as  the 
internal  data  structures  used  by  flan  are  identical  to  that  used 
by  the  FP . 


.'TwEv 
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3.3.2  Program  Organization 

The  actual  module  structure  was  refined  as  other  CIs  were 
developed  which  make  use  of  the  functionality  of  FLAN.  FLAN 
basicly  consists  of  a  lexical  analyzer,  an  LALR(l)  parser,  some 
semantic  procedures  and  a  code  generator  (writes  binary  Form 
Definition  files).  Syntax  errors  are  detected  by  the  lexical 
analyzer  and  parser.  Semantic  errors  are  detected  by  the 
semantic  procedures. 

3.3.3  Modification  Requirements 

The  use  of  a  parser  generator  makes  changes  to  the  Form 
Definition  Language  easy  to  implement  since  one  specifies  only 
the  grammar  and  not  the  parse  tables.  Using  existing  Form 
Processor  routines  ensures  that  changes  made  to  FP  data 
structures  and  procedures  will  require  few  changes  be  made  to 
FLAN ' s  procedures . 
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SECTION  4 

QUALITY  ASSURANCE  PROVISIONS 


4 . 1  Introduction  and  Definitions 

"Testing"  is  a  systematic  process  that  may  be  preplanned 
and  explicitly  stated.  Test  techniques  and  procedures  may  be 
defined  in  advance  and  a  sequence  of  test  steps  may  be 
specified.  “Debugging"  is  the  process  of  isolation  and 
correction  of  the  cause  of  an  error. 

"Antibugging"  is  defined  as  the  philosophy  of  writing 
programs  in  such  a  way  as  to  make  bugs  less  likely  to  occur  and 
when  they  do  occur,  to  make  them  more  noticeable  to  the 
programmer  and  the  user.  In  other  words,  as  much  error  checking 
as  is  practical  and  possible  in  each  routine  should  be 
performed . 

4.2  Computer  Programming  Test  and  Evaluation 

The  quality  assurance  provisions  for  test  consists  of  the 
normal  testing  techniques  that  are  accomplished  during  the 
construction  process.  They  consist  of  design  and  code 
walk-throughs,  unit  testing,  and  integration  testing.  These 
tests  are  performed  by  the  design  team.  Structured  design, 
design  walk-through  and  the  incorporation  of  "anti bugging" 
facilitate  this  testing  by  exposing  and  addressing  problem  areas 
before  they  become  coded  "bugs" . 

The  integration  testing  entails  use  of  a  test  application 
of  the  VAX.  This  test  program  displays  forms,  reads  input  from 
forms,  and  displays  results. 

Each  function  is  tested  separately,  then  the  entire  sub¬ 
system  is  tested  as  a  unit.  All  testing  is  done  on  the  IISS 
testbed  VAX. 
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SECTION  5 

PREPARATION  FOR  DELIVERY 


The  implementation  site  for  the  constructed  software  is  the 
ICAM  Integrated  Support  System  (IISS)  Test  Bed  site  located  at 
General  Electric,  Schenectady,  New  York.  The  software 
associated  with  each  CPCI  release  is  delivered  on  a  media  which 
is  compatible  with  the  IISS  Test  Bed.  The  release  is  clearly 
identified  and  includes  instructions  on  procedures  to  be 
followed  for  installation  of  the  release.  Integration  with  the 
other  IISS  CPCI ' s  will  be  done  on  the  IISS  TEST  BED  on  a 
schedu 1 ed  bas i s . 
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APPENDIX  A 

FORM  DEFINITION  LANGUAGE  SYNTAX 


This  document  uses  the  following  notation  to  describe  the 

syntax  of  the  FDL  entries: 

UPPER-CASE  identifies  reserved  words  that  have  specific 

meanings  in  the  FDL.  These  words  are 
generally  required  unless  the  portion  of  the 
statement  containing  them  is  itself 
optional . 

lower-case  identifies  names,  numbers,  or  character 

strings  that  the  user  must  supply. 

Initial  upper-case  identifies  a  statement  or  clause  that  is 

defined  later  on. 

_  Underscores  Identify  reserved  words  or  portions  of 

reserved  words  that  are  optional. 

{  }  Braces  enclosing  vertically  stacked  options 

indicate  that  one  of  the  enclosed  options  is 
required . 

[  ]  Brackets  indicate  that  the  enclosed  clause  or  option 

is  optional .  When  two  or  more  options  are 
vertically  stacked  within  the  brackets,  one 
or  none  of  them  may  be  specified. 

...  Ellipsis  indicates  that  the  preceding  statement  or 

clause  may  be  repeated  any  number  of  times. 
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Form  Definition 

CREATE  FORM  form_name 

[  SIZE  int-1  [  BY  int-2  ]  ] 

[  BACKGROUND  {BLACK}  ] 

{WHITE} 

t  PROMPT  Location  promptstring  ...  ] 

[  Field_Def ini t ion  ...  ] 

Field  Definition  -  Items 
ITEM  itemname  [  Repeat_Spec  ] 

Location 

[  SIZE  int-1  t  BY  int-2  ]  ] 

[  VALUE  {  string  constant  }  ] 

{  INDEX ( f i e 1 dname )  } 

{  ' ._TIME'  } 

{  ' .  DATE '  } 

{INPUT  } 

{OUTPUT} 

DISPLAY  AS  {HIDDEN} 

{TEXT  } 

t  LEFT  ]  [  UPPER  ] 

[  DOMAIN  (  [  RIGHT  ]  [  LOWER  ]  [  MUST  ENTER  ] 

t  MUST  FILL  ]  t  NUMERIC  ]  [  MAXIMUM  int-1] 

[  MINIMUM  int-2  ]  )  ] 

{  help_string  } 

[  HELP  {  help_f ormjname  }  ] 

{  APPLICATION  } 

[  PROMPT  Location  prompt_str ing  ...  ] 
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Field  Definition  -  Forms 
FORM  form_name  [  RepeatSpec  ] 

Location 

SIZE  int-1  [  BY  int-2  3 
[  PROMPT  Location  prompt_string  ...  ] 

Field  Definition  -  Windows 
WINDOW  windowsname  [  RepeatSpec  ] 

Location 

SIZE  int-1  [  BY  int-2  ] 

{BLACK  } 

[  BACKGROUND  {WHITE  }  1 

[  PROMPT  Location  promptstr ing  ...  ] 
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s 

n: 


2d 


a 


Locat i on 


[Rpt]  AT 


{  [  int  ]  {  LEFT  }  OF  [  fieldname  ]  }  +- 

(  {  RIGHT  )  }  \  AND 

{  COLUMN  int  }  +_ 

{  [  int  ]  {  BELOW  }  [  fieldname  ]  }  -+ 

{  {  ABOVE  }  }  i 

{  ROW  int  }-+ 

{  t  int  ]  {  ABOVE  }  [fieldname  ]  }  +- 

{  {  BELOW  }  }  i  AND 

{  ROW  int  }  +  _ 

(  t  int  ]  {  RIGHT  }  OF  [  fieldname  ]  }  -+ 

(  {  LEFT  }  }  i 

{  COLUMN  int  }  _+ 

(  [  int  ]  {  LEFT  }  OF  [  Rpt  OF  ]  [  field  name  ]  } 

{  {  RIGHT  }  “  } 

{  [  int  ]  {  ABOVE  }  [  Rpt  OF  ]  [  field  name  ]  } 

(  {  BELOW  }  } 

int-1  int-2  [RELATIVE  TO  [Rpt  OF]  [field  name]  } 


$ 

i. 


i 

& 


I  TOP  LEFT  l 

l  TOP  I 

l  TOP  RIGHT  I 

l  left  I 

<  CENTER 
I  RIGHT  I 

l  BOTTOM  LEFT  I 
l  BOTTOM  I 

I  BOTTOM  RIGHT  I 
\  / 


4 
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Repeat  Spec 


C  {  int-1  }  (HORIZONTAL)  [  WITH  int-3  SPACES  )  [. 

{  int-1 / int-2  }  (VERTICAL  } 

(  int-l/int-1  } 

(  *  ) 

{  int-1/  ‘  } 
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APPENDIX  B 


BINARY  FORM  DEFINITION  FILE  RECORD  STRUCTURES 


/ 


NAME 

fffv2.h  -  Form  File  Format  -  Version  2 
Written:  18-JUL-1984  13:03:25 
Revised:  18-JUL-1984  13:03:25  -  SCJONES 


DESCRIPTION 

Record  layouts  for  the  binary  form  definition  file 


typedef  struct 
{  char  rectyp; 
int  vernum ; 
char  linefeed; 


/*  version  number  record  */ 

/.  - 1  ■  ./ 

/•  current  version  number  (2)  */ 
}  VERREC; 


typedef  struct  /•  form  record  •/ 

{  char  form  name[10];  /•  form  name  •/ 


char 

background! 10] 

/ *  background  name  * / 

short 

row ; 

/*  starting  row  •/ 

short 

col  ; 

/•  starting  col  •/ 

short 

width ; 

/*  width  •/ 

short 

depth ; 

/ *  depth  • / 

short 

ntxtf Ids ; 

/*  number  of  text  fields  */ 

short 

ndatf Ids ; 

/•  number  of  data  fields  */ 

short 

stxtbuf ; 

/•  size  of  the  text  buffer  •/ 

short 

sdefbuf ; 

/•  size  of  the  default  buffer 

char 

1 inef eed ; 

} 

FRMREC ; 

typedef 

struct 

/  * 

text  record  • / 

{  short  row; 

'  *  starting  row  • ' 

short 

col  ; 

/  • 

starting  col  •/ 

short 

len ; 

/  * 

total  length  • . 

char 

1  inef eed ; 

) 

TXTREC ; 

typedef 

struct 

/* 

field  record  •/ 

{  char  fid  name [10];  /*  field  name  */ 

char 

f ldtype ; 

/•  field  type  (F,  I.  W,  A)  •/ 

short 

row ; 

/•  starting  row  •/ 

short 

col  ; 

/*  starting  col  •/ 

short 

width; 

/•  field  width  •/ 

short 

depth ; 

/*  field  depth  •/ 

int 

min  value ; 

/•  minimum  value  (if  any)  •/ 
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int  sax  value: 
char  helpl ine[ 80] . 
char  dispattj 10] ; 
short  n_f ormats ; 
char  format [ 12] [2] ; 
short  n  arydef s ; 
struct  /*  dimens 

{  char  dir; 

short  cnt ; 
short  sp;  /• 

short  dsp  size; 

)  array  def [3] ; 


/*  aaxiBUB  value  (if  any)  * 

/*  help  text  •/ 

/•  display  attribute  *  - 
/*  number  of  formats  •/ 

/*  format  strings  •/ 

/*  number  of  dimensions  •/ 
ion  specification  */ 

/•  repeat  direction  (H.  V)  • 
/*  actual  repeat  count  •' 
number  of  spaces  between  repetitions 
/•  display  repeat  count  •/ 
char  linefeed:  }  FLDREC : 


B-2 


•i  1  >'*■  *  198-’ 
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